Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show arguments names in tooltips for local functions #13429

Merged
merged 2 commits into from
Jul 4, 2022

Conversation

psfinaki
Copy link
Member

@psfinaki psfinaki commented Jul 1, 2022

partially fixes #7080

So basically local functions were missing value representation info which the tooltips are relying on. This is fixed by calling AdjustValToTopVal function which sets this value representation (aka top val info) in the right place.

image

Note that this doesn't fix the other case described in the issue, see @dsyme's comment.
image

@psfinaki psfinaki requested a review from dsyme July 1, 2022 13:28
@auduchinok
Copy link
Member

@psfinaki Could you also check if it fixes FSharpMemberOrFunctionOrValue.DeclaringEntity for bindings inside types?

module Test =
type T() =
let fu$$nc x = ()
"""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also add a test for bindings that are local to other expressions, not types?

do
    let func x = ()
    ()

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually looks like this case is not working yet, hah. Looking into that

@psfinaki
Copy link
Member Author

psfinaki commented Jul 1, 2022

@psfinaki Could you also check if it fixes FSharpMemberOrFunctionOrValue.DeclaringEntity for bindings inside types?

@auduchinok Sooo likely yes, looks like that
image

@psfinaki
Copy link
Member Author

psfinaki commented Jul 1, 2022

So apparently we already had tests verifying the wrong behavior so will do something about those as well :D

@dsyme
Copy link
Contributor

dsyme commented Jul 3, 2022

Could you also add a test for bindings that are local to other expressions, not types?

I think this should be done in a separate PR. I suspect it's considerably harder

In particular I believe we can't set ValReprInfo for Val contained in expressions without mucking with later compilation (e.g. confusing IlxGen or later phases)

Note the class-bound Val being adjusted in this PR are ephemeral nodes used during type checking that are not actually present in the TypedTree (they get replaced by new member Vals), and are not relevant to later compilation. The expression-bound Val are not like this - they are present in the typed tree.

Possible solutions:

  • It's possible we could set the ValReprInfo "for IDE purposes only" using some compiler switch. But we should think carefully before doing that as if we ever start using the symbols outside the IDE (e.g. incremental compilation) there would be problems. And perhaps it mucks with some IDE-visible logic anyway.

  • It's possible we could save the ValReprInfo in an IDE-only lookaside structure via the Sink. However it would then be a bit annoying to plumb it back to the routines that actually need it. Possible but annoying.

  • It's possible we could do cleanup work to make it possible to distinguish the two roles of ValReprInfo - one to give good names for the IDE, and one to guide the "exact compiled form" of constructs.

@psfinaki
Copy link
Member Author

psfinaki commented Jul 4, 2022

So I fixed the tests, updated the description, @auduchinok we'll address the other broken case separately, I'm all up for smaller PRs :)

@psfinaki
Copy link
Member Author

psfinaki commented Jul 4, 2022

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@dsyme dsyme merged commit 0d88a9c into dotnet:main Jul 4, 2022
@dsyme
Copy link
Contributor

dsyme commented Jul 4, 2022

Great to have this case fixed!

@psfinaki psfinaki deleted the psfinaki/7080 branch July 4, 2022 15:40
@auduchinok
Copy link
Member

auduchinok commented Jul 6, 2022

It's possible we could do cleanup work to make it possible to distinguish the two roles of ValReprInfo - one to give good names for the IDE, and one to guide the "exact compiled form" of constructs.

This sounds like the best option.

It's possible we could save the ValReprInfo in an IDE-only lookaside structure via the Sink. However it would then be a bit annoying to plumb it back to the routines that actually need it. Possible but annoying.

And this one is good enough if it's considerably easier to do than the previous one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Intellisense tooltip for local functions should show argument names
3 participants